On Tue, 25 May 1999 16:24:14 -0500, Tim Hutcheson wrote:
>> Fix all of the global variables and other weirdness (like variable reuse)
>> and then it would be a fairly easy task.
>
>Agreed.
>
>But usually you can find some low level which sacrifices generality and
>elegance (but avoids the globals problem) in critical routines that can be
>threaded to yield 90 percent of the performance improvement without doing a
>full-up SMP design.  Kind of a thread-lite approach.  I have had some
>surprising results with a little effort on routines that I thought were
>impossible to multi-thread, like fuzzy c-means clustering (FCM).  That
>involved splitting the image work into two threads, synchronizing completion
>and then doing a final pass to merge the results.  But it essentially
>doubled the performance with two processors.
>
>I have the source installed, what's a good candidate routine?

That's the problem, there is no good candidate routine.  The best way to 
parallelize POV is by tracing different rays in different threads, but 
it's the code that traces a ray that isn't threadsafe, and the problems
are spread throughout the code.  Somewhere in excess of 90% of the code
is called from within the "trace a ray" function at one time or another.

As an example of some things that aren't thread safe:

o The crackle pattern generates an array of nearby centers to determine 
  where it is within the voronoi diagram.  This array is a global 
  variable and is cached from use to use.  If two threads are rendering
  a crackle pattern at the same time, one could refill this array while
  the other is trying to calculate with it.  If you serialize access to
  it, you may end up serializing some scenes entirely.  If you eliminate
  the caching, you will slow down the trace considerably.

o The area light code saves off the center of the light source into a
  local variable, "fiddles" with it during the calculations, then 
  restores it when it's done.  Hopefully it's obvious why this isn't
  threadsafe.

o The crackle pattern saves the current RNG seed before filling its array, 
  then restores it afterward.  While filling its array, it depends on the 
  sequence of "random" numbers being reproducible.  The black hole warp 
  is similarly dependent.  If one thread came in and grabbed a random
  number while another thread was inside this code, the image would be
  ruined in a very obvious manner.  

o Some code apparently depends on the RNG being repeatable, as one of the
  changes in a recent update was the saving and restoring of the RNG seed
  mentioned in the previous point.  If two or more threads are using the
  same RNG, it will not be repeatable.

o The radiosity code saves some global settings, modifies them, and then 
  restores them later.

o Determine_Apparent_Colour - a very important, central function - saves
  the texture, weight, and light lists before doing whatever it does, then
  restores them afterward.

Post a reply to this message